Message
routing might seem very easy in small organizations like the one in the
Contoso scenario, but it gets more complex as the organization grows.
For larger organizations, you definitely have to understand all the possibilities and
parameters available to you for planning, configuring, and optimizing
message routing.
1. Message Routing within an Exchange Organization
In Exchange versions prior to
2007 you defined message routing inside an Exchange organization by
using routing groups and routing group connectors. Exchange Server 2007
introduced changes to internal message routing that are still valid for Exchange 2010:
The
message-routing topology and routing decisions are based on the Active
Directory site topology (Active Directory sites and IP site links).
Routing is configured automatically, so you do not need to configure any routing group connectors.
The SMTP protocol is used for all message transport.
Note: Exchange Server 2010 automatically creates internal
Send connectors on Hub Transport servers that are required for mail
flow within the organization. These are implicit connectors that are
not visible in the Exchange management tools, and you cannot modify them.
Table 1 provides an overview of internal message routing in Exchange Server 2007 and Exchange Server 2010 as it correlates to Exchange 2000 and Exchange 2003.
Table 1. Routing Comparison Between Exchange Versions
| EXCHANGE SERVER 2007 AND EXCHANGE SERVER 2010 | EXCHANGE SERVER 2000 AND EXCHANGE SERVER 2003 |
|---|
| Hub Transport server | Dedicated bridgehead server |
| Active Directory site | Routing group |
| IP site link | Routing group connector |
| Cost of IP site link | Cost of routing group connector |
1.1. Point to Point Routing in Exchange 2010
The Hub Transport server role is the only Exchange server role that can route messages within an Exchange organization. Of course, the Edge Transport role can also route messages, but only to and from the Internet.
Note: Since
Exchange Server 2007, all messages in Exchange 2010 flow through a Hub
Transport server, even if the recipient is on the same Mailbox server
as the sender.
Internal message routing in Exchange Server 2010 is also known as Point to Point routing and follows two basic rules:
If the message target
recipient is within the same Active Directory site, the Hub Transport
server delivers the message directly to the Mailbox server where the
recipient mailbox resides.
If the message is addressed to a recipient located in a different Active Directory site, the Hub Transport server sends it directly to a Hub Transport server in the target Active Directory site. This means that the message does not relay to each Active Directory site along the least-cost routing
path as Exchange versions before 2007 did! It will choose the target
Hub Transport server using round-robin load-balancing mechanisms. Only
if the selected Hub Transport server becomes unavailable will it choose
another Hub Transport server.
Note: By
default Hub Transport and Edge Transport servers communicate with each
other using TLS over SMTP. This means that the communication between
the servers is always encrypted, even if the message transmitted is not
encrypted. TLS uses the local digital certificate available on the
Exchange server. If you did not configure a certificate it uses the
self-signed certificate that was created when Exchange was installed.
Most
large-scale network environments are complex, so some situations
require special configurations. What happens when the target Active
Directory site is offline because of network problems? What happens to
firewall settings where network traffic is forced to flow through
specific Active Directory sites? These issues are covered in the
following paragraphs.
|
Andy Schan
Senior Consultant, Schan Consulting Inc., Canada
By default Hub Transport
to Hub Transport communication is encrypted using TLS. However, if your
company uses WAN Optimizing Controller (WOC) devices, you might want to
turn off TLS to optimize the WAN traffic using this device. Exchange
2010 now supports disabling TLS to support this scenario. If you have a
specific WAN link you want to disable TLS for, you basically configure
a Hub Site for both Active Directory sites (the Active Directory sites
between the link) so that no messages are sent directly to the target
site but stop before the link with the WOC device. Then you create new
Receive connectors for both sites using the IP address range of the
distant site and configure the Receive connectors to disable TLS.
Now all messages that want to
use the WAN link are sent without using TLS encryption; thus the WOC
device can optimize the traffic. You can find more details how to
configure it at http://technet.microsoft.com/en-us/library/ee633456.aspx.
|
1.2. Exchange 2010 Version-Based Routing
Exchange Server 2010 also implemented a new transport server routing rule called Version-Based Routing or just Versioned Routing.
This rule means that a Hub Transport can only communicate with a
Mailbox server role of the same Exchange version. The idea behind
version-based routing is that different and incompatible versions of
the Exchange API used to get messages in and out of the store are implemented in Exchange 2007 and 2010. An
Exchange 2010 server cannot talk directly to an Exchange 2007 mailbox
server and vice versa. However, the Hub Transport servers of both
versions can communicate together.
If you have Exchange 2007
and Exchange 2010 servers in your organization located in the same
Active Directory site, the rule prevents Exchange 2007 Hub Transport
servers from directly communicating with Exchange 2010 Mailbox servers
and Exchange 2010 Hub Transport servers from communicating to Exchange
2007 Mailbox servers.
In the Fabrikam scenario
this will be the situation during migration. During that time, all
messages sent from Exchange 2007 mailboxes to Exchange 2010 mailboxes
will be sent from the Exchange 2007 Mailbox server to the Exchange 2007
Hub Transport, and from there will be transferred to the Exchange 2010
Hub transport and then to the Exchange 2010 Mailbox server.
Version-based routing was
implemented to overcome the requirement to have separate Active
Directory sites for Exchange 2010 servers.
1.3. Least-Cost Routing Path
When multiple routing
paths exist for a message, the routing path is calculated based on an
algorithm to select a single path over which the message will be
routed. This is called least-cost routing path calculation and it uses the following logic:
Calculate the cost
to the target Active Directory site by adding all IP site link costs or
connector costs between the source and the target site. If an Exchange
cost is configured on an IP site link, the Exchange cost is used
instead of the Active Directory cost. If there are multiple paths, only
the path with the lowest aggregated cost will be used.
If there are multiple paths with the same lowest aggregated costs, the routing path with the fewest hops is selected.
If
multiple paths are still available, the site name with the lowest
alphanumeric name is selected. Starting with the site name to the
target Active Directory site, the algorithm will go backward along the
path until it finds a site name that doesn't match.
Note: Other factors, such as message size limits or connector scope, can influence the least-cost routing path.
The two concepts
described in the following sections are based on the least-cost routing
path: queue at point of failure and delayed fan-out.
1.3.1. Queue at Point of Failure
If a Hub Transport server cannot deliver a message to a Hub Transport server in the destination site, the Hub Transport server uses the least-cost routing path to deliver the message as close as possible to the destination site. This is called queue at point of failure.
Technically, the least-cost
routing path will be used in reverse order: from the destination Active
Directory site to the source Active Directory site. All Active
Directory sites are contacted along this path, and if a Hub Transport
server is available, the message is queued there in a retry state. Thus
the message is delivered to a Hub Transport server that seems to be the
closest one to the target Hub Transport server from the IP site link cost
perspective. If Hub Transport servers are not available in any site
along the least-cost route, the message is queued on the local Hub
Transport server.
For example, use the
Litware scenario and assume all site link costs are the same and the
links are configured exactly as shown in Figure 1.
Now a message is sent from
Madrid to Houston. Normally the Hub Transport server of Madrid would
directly connect to a Hub Transport server in Houston to submit the
message. However, if no Hub Transport server in Houston is reachable,
the message cannot be sent directly.
Queue at point of failure
takes place and the closest site to Houston that has Hub Transport
servers is selected. In this example, the message is transferred to a
Hub Transport server in Fresno because Fresno is closer to Houston than
Madrid.
1.3.2. Delayed Fan-Out
When sending a message that is addressed to multiple recipients, point-to-point routing normally means creating a copy of the message for every Exchange server that hosts a recipient and sending the message to the target Hub Transport servers directly. However, Exchange Server 2010 uses a technique called delayed fan-out to preserve bandwidth when routing messages with many recipients.
After each recipient has
been resolved by the Hub Transport server, Exchange Server 2010
compares the routing path for each recipient. The splitting of messages
into multiple copies does not occur until a Hub Transport server is
reached, which splits up the routing path. Microsoft calls such a Hub
Transport server a fork in the routing path.
Take a look at the Litware scenario in Figure 5-6.
A message is sent from Madrid to recipients in Fresno, Houston, and
Anaheim. Because of delayed fan-out, a single message is then
transferred to Fresno, where the local Hub Transport delivers a local
copy to the Fresno recipient, then creates two copies of the message,
sending one to Houston and one to Anaheim. As you can see, especially
for messages with large numbers of recipients, this feature saves a lot
of bandwidth.
1.4. External Routing Connector Selection Process
Exchange 2010 also
needs to decide what Send connector it will use to route messages that
are destined to the organizational parameter network such as the
Internet. This selection process is done by first eliminating all
connectors whose message size restrictions are less than the size of
the message to be routed and then determining a single connector using
the following steps:
The
connector must be enabled; if the connector is a scoped send connector,
it must be in-scope for the local Hub Transport server and the address
space must include the recipient's domain. (In other words, the
connector must appear in the hub transport server's routing table.)
If more connectors remain, the most specific address space match will be used.
If still more than one connector matches, the following logic will be used until a unique connector is identified:
Connector cost (All IP site link costs are aggregated.)
Proximity
(A local server is chosen over another Hub Transport server in the same
Active Directory site, and a server in the local Active Directory site
is chosen over a source server in a remote Active Directory site.)
Alphanumerically (The lowest connector name will be used—for example, ConnectorA will be preferred over ConnectorB.)
Note: Remember
that this selection process takes place at every Hub Transport server
along the routing path used by the message. If there is a scoped
connector along the least-cost routing path available that includes the
address space, the route may change when the message is routed through
this Active Directory site.
1.5. Routing Table
Every Hub Transport or Edge Transport server calculates the routing
topology based on the Active Directory configuration. This includes
Active Directory sites, Active Directory site links, Exchange servers
and their relation to Active Directory sites, SMTP connectors,
third-party connectors, mailbox and public folder stores, and legacy
Exchange 2003 routing groups and connectors. This will make up what is
called the routing table. A routing table is built every time one of the following events occurs:
The Microsoft Exchange Transport service is started.
After a periodic reload interval (six hours by default).
After Active Directory change notifications such as changes in Active Directory site links.
Note: All
Active Directory changes are collected into a batch to process them in
a single operation. Each notification causes a five-second delay; thus
if many changes occur at the same time, routing calculation is delayed
until all changes are received and then processed as a single operation.
By default, the routing table log files can be found in <Exchange_Installation_Path>\ TransportRoles\Logs\Routing.
Using the Set-TransportServer cmdlet as listed in Table 2, you can configure a few parameters to configure the routing table creation.
Table 2. Set-TransportServer Options for Routing Table Configuration
| PARAMETER | DESCRIPTION |
|---|
| RoutingTableLogPath | Specify the location of the routing table log files. |
| RoutingTableLogMaxDirectorySize | Specify a maximum size for the directory that contains routing table log files. Default: 50 MB. |
| RoutingTableLogMaxAge | Specify a maximum age for the routing table log files. Default: 7 days. |
In addition to these
parameters, you can configure the periodic interval the routing table
is automatically recalculated using the RoutingConfigReloadInterval parameter in the EdgeTransport.exe.config
file. By default, this is set to 12 hours but because every Transport
server renews its Kerberos token after 6 hours, the routing table is
created more frequently. This means that other parameters interfere
with changing the RoutingConfigReloadInterval parameter, so you should be careful when changing it.
You can view the Routing
Table logs using the Routing Log Viewer available in Exchange
Management Console.
